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Svstcan and met hod for executin^^ rndbuilding a software a yj^^^ 




The present invention relates to a system and a 
s^lication. Furthermo^» the present invration relates to a 
building a software applicdliozx. 

In present systems and methods for bnildiiJig software 
standaidisBd software padcage is bougbt by a company, anc 
adapted to the software padcage or a software application is 
tested to suit the specific needs of a company. In the first cj sh, 
lacks flexibifity in use, is often difficult to integrate into exi 
offers too much, too httlc or the wrong functionality. In the 
software development before operational use is often long « iM 

Principal to these known software developm^t strate gu 
prograronung and testing of software oode^ Different sp< 
competencies are involved m a sequential, and often also il 
operational software application is obtained. This requires 
time and cx^st. 

Another example is disclosed in the international patddt 
WOOl/014962. ^Iiich describes a method and ^paratus fo : >: 
configurable business applications fiom a standardized set < )i 
method and apparatus, a modular set of components are us< <| 
service ajiplication according to user requirements, 
comprise busmess steps (operations wilh a defined set 
busmess rules (which capture customer specific business p^abi 
componmts are thus adapted to a specific business service 
qpproach still requires a great deal of detailed programming 
advantages as described in this present invention. 

The present invention sedcs to provide a s; 
software application wMdi shortens fiie time to operationa] 
application, and provides a better cost efBciency delivejifi^ 
ipplicadon. 

The foundation of such a system and method is descr^t 
q>pUcation PCT/KLOl/00926, of the same applicant as 
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Led, programmed and 
;uch a software padcage 
s^ijijg systeoos and usually 
ca2ie, die complete 
4^ensive» 

is that it involves 
t^with^tifferent 

ma oner before an 
;^ invesi ments, both in 
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»:i»vidin| custom 
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consufuct a busmess 
components 
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;|i{ce$). hi this case, fiie 
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20 ^plication. This can be a software application in any state. 



that is already running or a software application to b e buill * p e spec ification is 
'abstract*, because it concmtrates on data classes, user groi igs md pei missions. JX can 
define a con^tlete software q)pfication wiftiout liaving to n e|pk buuser inter&ce details. 
The specificaticmis *exact\ because it sufBoiently desciibes a iM^ftwa e applicatioato 
allow the gaeric plication engoie to generate the oomph t » c jpeiatic »nal software 
application. An q)plicationipecification is usually the result i[i>m an information 
analysis, but can also be (partly) demed 



fii this description of the invention, flie focus is on a box 
application oigine. &i ttiis style of c4>eration, ftie q»plicado i s ^teificadion 
a geximc qiplication ragine, after which the generic spplk A<^\k m&J^ 
desired behaviour of the software ^plicadoa However, in 
operation, the process can be subdivided in s<^>arate steps 



PCt/NU€03/000«)6 



an 



Accozding to a first aspect of flie present invention, a sy: !i em is ] >n>vidfid for 
executing a software qyplication comprising a computer sy: 1 3i ( corniced to a plurality 
ofinput^outputinted&ces and a database, tiie computer systet leing^irrangedfor 
in^lementing a generic application engine and for receivin ; a c i appUc ation 

5 specification as izqnit for the generic application engine> wl ih \ gemeri :^ ^plication 
engine is connected to the plurality of ii^ut/output inter&D J i u id to the database, the 
generic application en^ne being airaqged to use a set of fix icl i mal cg nqK)neiite» such 
as database operationSi logical operations, presentation fm 1|< is, use : input^output 
inter&ces, logging and monitoring, to convot Ifae i^plicati m ^ecifidation into the 

10 software application, the application specification comprisi og 

a) a specification of a plurality of data classes, a data cis s s heink a description of 
objects relevant within die software ^plication, and the plif4()^ of djata classes 
fomiing a structure by means of relations; 

b) a specification of at least one user groD^ of the $oMd» application, a us^ 
IS giroup being defined as a group of users having common roji^^ fdth regard to the 

spfiwaie i^lication; and 

: c) an assignment of p^missions to the at least one vis^ ^ovip w|ith respect to the 
plurality of data classes. 
i An application specification is an abstract, but exact,|sp^|nficatibn of a software 



a software qqplication 



is loaded into 
executes the 
ive style of 



( Itema^r 
irk I, exec Uable software 
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^tyle of opeFati(m» tbe 



mc behaviour of Ae 



5 standard components of the generic application en^ne. Jsx \ 
original q>plioatioa specificalion can $tiU be used to contxol 
software applicadon. This alternative stjde of opecation deli m & more < xuitrol to tihe 
programmer^ and provides more possibilities to adapt the so are zipp lication 

The alternative style of operation can be iixqplemented . tising the same q)plication 

10 specification as in the iSist style, and producing software co< le hat, vdlen executed, 

I 

provides the same functionality as in the first style. There ai ^"sleveral ways to generate 
software code fiom &e application specification, mainly dej )ec dent on the desired 
relation between the generated code and the standard compc iixdots. Sin ^ the conc^t of 
code generadon from a model is common hi the field, this s yie of operation is not 
IS described in fiirflier detail From tbe description of the first i ?ty|e, it wi|l be apparent to 
ihe person sldUed in the art, how to create an in^lementatioa|c >f the alternative style. 

The term 'data class' as mentioned in this description i 
standard obj ect oriented modelling (usually a class is koowA | 
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any piogrammmg 



code is created from (parts of) the ^plication specification 
language), hi a second step this generated software code ma /|e/en be modified by a 
human programmer in ord» to change functionality and/or i qpipearance . Finally^ die 
generated (and possibly modifiecQ sofhvare code can run, p( m bly togethex- with 



iers to d 'class* in 

a descnption of objects 



having common charftcteristics). However, the essentials of l|d s desci^tion and this 
20 invention can also be q>pli6d on ^entities' as they are knowi i ju: i the area of conventional 

datamodelling I 

The term ^relation' as mrationed m this description re feis to a stjructural 

relationship between two data classes, commonly known as aL *associLtioa* (e.g. see 

Unified Modeling Language). Each relation also has ^multi] )|c it/» which ts an 
25 mdication of how many objects may participate at eiflier en i p|^^ re^on. Hie most 

common multiplicities are 1, * (0 to mfinity), asd 0..1 (eithi xmone or one). The 

relations themselves mig^t be of type: one-to-one, one4o-niany or many-to-many, as is 

commonly known m the area of entity relationship modellh A 

When two data classes are related, ttie data class on tl qone-sidelof the 



30 relationship Cif any) is called die ^foreign dass% while the 
of the relationship (if any) is called tbe 'connected class'. A 
multiplicity with respect to this relation. A fordgn class 
Or 1 with respect to ttiis relation. At nm time the relationshib 



a class oh the many-side 
>nnecte4 class usually has 
iy hasj multiplicity 0..1 
ileadi to related 
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objects. An object of tbe fordgn class is called 'foreign objs&t', while an object of tfie 
connected class is called ^connected otgect'. When a data c J$s A h^ a connected class 
B, and class B has a connected class C, tfien C is an indirect ppnnected class of A. 

The term 'user' as mentioaed in this description may ^ )e understood as being an 
individual user» interacting with ttie software application via a (graphical) user interim 
(input and output), or a furth^ software or hardware appUcanon (using appropriate 
interfaces). In simple software q)plications. dxere may be o up single user group, being 
an anonymous or default user group, | 

In a fiuth^ aspect, the present invention relates to a f jostem for building a 
software application comprising an input/output device, mt mory means and processing 
means connected to the input/output device and memory n ^tts, the processing means 
^ being arranged for defining an application specification^ us up flie input/output device, 
^ and to store the sq[)plication specification in the memory mi lagos, which application 
specification can be input in a syst^ for executing a softip< ore application according to 
15 ^ the present invention. Such a system, also referenced as w^xkbendi or specification 
% editor, allows to create an application specification for inpi \mo the generic ^plication 
- engine in Older to create the software application^ | 
t In an evfflfiirther aspect, the present invention provi[lp forexecuting 
? a software appficationconsprising inputting an q>plication sp 
. application engine, wfaidi generic application engine is cox nected to apluiality of 
i ixq>ut/output interfaces and to a database the generic appli< engiw being arranged 
. to use a set of functional components, such as database op< rations, logical opexations, 
presentation fimcdons, user input/ou4}tttinter&ce%bggu^S mdmomtoring, to convert 
the application specification into the software sQiplicatiOQ, 1 e applicaition specification 
comprising: 

a) a specification of a plurality of data classes a data class being a description of 
objects relevant within the software appUcation, and the pi Qc aUty of data cte^ 
forming a structure by means of relations; 

b) a specification of at least one user group of the soi t me application, auser 
ffoup being defined as a group of usm having common k1 »s with r^^anrd to the 
software q>pIication; and 

c) an assigmnent of permissions to the at least one el- group witii respect to the 
plureli^ of data classes. 
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Accozding to an oven furdier aspect of Ifae present inveittion, ajpefhod is 
provided for building a software application comprising de fi ofing an application 

specification and storing the application specification, whi< ^ application ^edfication 

I 

is arranged to b e used in a metibod for executing a software applicatian according to the 
5 present invention. 

Widi the systems and methods according to the presc rk invention, it is possible to 
develop an operational software application to suit specific ijeeds by only specifying 
the ftmctionality of the software ^plication, The software plication is built, with 
considerably less detailed programmiAg, This also allows for easier maintenance and 

10 lEuture upgicades, as only the application specification needj \ |q be updated 

The application spedfication used in the present inve i^on serves various targets. 
First, it can be entered in the generic ^plication engine to :^|edte the numing software 
application. Secondly, from the plication specification s( imts can be derived to 
CTeate or modify the database structure that is used to store me application's data. 

IS Moreover, the application specification may be useful in oilra: areas^ sudi as 

management and support or other organisational areas^ e.g education and training. 

The piesmt invention dxus allows to make a soltwan \ ipplicadon with any usual 
fbnctionaUty of a modem software ^ypUcation on a vaziet)! ( f fields, such as archiving^ 
call cenlxe applications, woikflow. customer relationship nu dagement, e-commerce, 

20 content management, etc. The present system and method 1 1! 61 particularly a<^^ 
when using (multiple) databases with complex data model: when usmg various user 
gfxnsp s with difieient aufliorisations, or ^en using deduct c A rules. 

The generic application engine conqyrises functional t I'^faich is often present in 
software qiplications, Le. database cperations, business logi sl'hiles, presentation 

25 fimctioiis, user inputA)utput intetfiices, logging and monito t^sg. The generic application 
engine uses known technical standards, such as SQL, XMl JxSL, JAVA, HTTP, 
SOAP. I ' 

The generic a{)plication engine allows to select data, read data, lock data, join 
data, sort data, insert data, copy data, update data and delet e|data in a database, to 

30 import and export data fiom/to files, such as XML-files, az 4 to synchronise database 
copies. Business logic can be supported and executed in several ways. Deduction rules 
(formulas, etc.) may be automatically executed in order to d^uce daGa. Validation ndes 
can be executed to validate user izqmt Additional constrah ttb might be used to create 



21 FEB. 2005 11:20 



NEO.OCTROOIBUREAU 31 70 3527528 



wo 2004/02117* 



specific sdections of data or loolcup lists. Event triggers can ife used to m^lement work 
flows. Finally, specific procedures cdn be implemented that ^ be executed on user 
requests. 

For preseotalioa of data on a screen, tide geiieric i^fi^on cogme uses various 
S scte» layouts, such as tree, tabular and cross table represen talons. Data may be 
selected, presented (6.g. u^g 8in:q)le grimes), n)odified at id iq>loaded. Other input 
and output is possible using tfie generic application engmG!, ^ using interfaces to smd 
andrecdve e-mail, faxes, sms, etc.i read and write files (tx^ xiM. csf), or exchange data 
with other programs, e.g. using HTTP, CORBA or SOAP, ikfeo, fba^ genaic epplication 
10 engine is arranged to log all use of Oie software plication, mi to process the logged 



data. 



NR. 770 P. 17 
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^ The term ^select' in this description reiers to the actionicjf constructing oitezia, 

^ and flying these criteria on a data class in order to get a sjobset of objects. The values 

of one or more fields of &e selected objects are presented ia k jUst or tdble. The term 
^ 15 'select' can be exchanged by tiixe term ^seardi'. From this li^ior table the other details 

^ of each object can be accessed. e.g. by selecting a row and/oil; activating a button. 

I 

u The terms 'modify' and 'modification' , used in this ddiqription in relation to data 

I j • 

* objects, refer to one or more of the following actions; ins^ ^^yt delete and update. 
The term 'tQidate' only refers to alt^ing values of fields of jekjsting otgects* 

j i| • 

20 hi the area of data prooessingi other systems and mettjidds are present, trying to 

cope with the same problems. Common in the field is the a^K^oinaric construction of 

simple user int^faces for selecting readmg and editing data jt>jr one data class, derived 

i ^ ^ 

finom a data model. However, none of these metttods and sy^^tbkns is as extended as the 
present invention. Hie present invoition opeates the possibijU^y to deliver complete 
25 software qyplications, vitb a set of inteixelated iiqput/outjpui; devices, e.g. soeens, each 
screen having mtcgrated fimctionality for more fiian one dapii ^ass (e. g. provided with 
trees or tab panels), and providing exact functionality for d^fifqrent users (based on roles 
and/or permissions), without having to specify Hue ix^u^oujljut devices tfaemfielves. 
The present invention offers ttiese possibilities (that otibor qi^Oiods and qrstems do not 

I ! \ 

30 ofier) by only combining a cai^tty considered and well-4^(Sutght-out stnicture for an 
q^lication specification with a smart and stable generic eqppfication engine. This 
innovative system and mediod for creating (enteiprise-wid^) sbftware i^Ucations is 
new in file area of data processing. [ ; 
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Id an anbodimoit of die jneseot inveutiooi, a data clas$!ma»ichy is defined in the 
application specification by spedi^ing an extoided data class !as conqoiang one or 

I 

more inherited charactmstics of an associated super data clias$* Hie use of data class 
hierarchy inczea$e$ die spedficadon pow^ of &e geixeric ^rplicatioxi eogiiie^ and 
5 albw5 Sat faster development and easier maintenance of soifiwaze q^plications. 

In an embodiment of die pies^ system or mefhod, the plication c^>ecification 
comprises for each of the plurality of data classes a specifidO&n of a plurality of fields, 
each field rqireseoting an element for storing data values related to an object 
In an even findier embodimeot of die present invention* • a field faiecarcihy is 

10 defined in the application specification by sp^nfying an extraded field as conqprising 
one or more inh^ted field diaractedsdcs of an associated saper field. As it is not 
needed to specify all fields of data classes completely, development of software 
applications can be fiister, and maintenance can be easier. 

In a fuitiier embodiment of the present system or mettod, the application 

15 specification may comprise for each of the plurality of data classes a ^ecification of a 
plurality of categories, which can be used to structure all dateiirelated to an object This 
structure is used by the generic application engine to present data to the user in a 
comprehensible way. 

In another fiitlher onbodimrat, the application specification may comprise a 

20 specification of a plurality of domains^ a domain being a list tff looloip values that can 
be ref^enced to fi-om the specification of fields. Domains aze used to sii]q;>lify 
selecting, reading and modifying objects. 

According to an even finther embodiment, for a specific combination of user 
group and data class, or a specific combination of user group and field, die penniaaions 

25 arechosen fimn the set of. select pmnission; esxportpemdstion; read permission; 

update pennission; msert pomission; copy penocdssion; ddete pennisaion. The vahie of 
eachpemiission is one of fhc group of: no; yes; fi>Uow foreign object; own; constraint 
This allows to define the intenelationship between user groups and data classes and/or 
fidids in a$u£5cient scope to be able to develop various sofiware applications. 

30 In a fintber embodiment, the application specification conq>rises a conq>utational 

specification for describii^g fiirtfaer computational parts of the software application. 
Certain software applications require additional logical opezafions on flieir data, 
can not be specified using the application pacification as described above. In tiiis 
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embodiment* a moie btoad spectrum of possible software q}plicaiioa& may be 
developed using the preseat inventive system and mediod. 

The applicatioix spedfication may in a furtfaer embodiment comprise an 
appeaiance specification Sot defining non-fiinctional parts of the software aiq)licatioOs 
5 such as user interfice parts. The generic ^licadon eng^e includes standard 

input/output of data from the software applicad<m. Using an ^eaiaoce Gpecification, 
the layout of the presented data maybe altered and specified to specific usor needs. 
Furfiier advantageous embodiments are given in die other dependent claims. 
\ A fixrther aspect of the present invention relates to a computer program product 

! 1 0 comprisiiig coxnputer readable code* which allows a computer wfam loaded with ilie: 

- computer readable code to implement a genmc application engine as used in the \ 

f system or mettiod according to the present invention. This allows the software code of 

i the generic q>pUcation enghie to be distributed to other computer systems, e.g. using a 

I data carrier such as a Q)» or using a computer netwotkcozmection, such as ^ 

t 15 An even further aspect of the present invention relates to a computer program^ 

-^^ product comprising computer r&adable code, which allows a computer v/bsa loadedi 

3 ivith the con4>uteT readable code to define an s^lication specification which is adapted 

t to be entered in a generic plication engine nmniqg on tibe computet; the plication 

specification cono^rising: 
20 a) a specification ofaptoraUtyofdata classes, a data dUss being a descxr^ 

{ objects relevant within the software plication, and the plurality of data classes < 

forming a structure by means of relations; .« 

b) a^)ecificationof at least one user gmxp of the software application^ aus^ 
group being defined as a groiq) of users having common roles with regard to the 

25 software application; and 

c) an assignment of pennissions to die at least one user gnnq> "^tti respect to the 
plurality of data classes. 

This will allow to provide a computer with the ability to build the application 
specification necessary to execute the software q)plication^ 
30 The present invention wiUiiow be described in fiirdier detail 

exemplary embodiments, with reference to file attached drawings, in which: 

Elg. 1 shows a schematic view of the execution environment of a software 
application according to the present invention; 
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Fig. 2 shews a sdienuitic view of the compositioa of an applicatioa specification 
according to an embodiment of the present invention; 

Fig. 3 sliowaaschemadcviewofasystemiisedinlfaepiesemi^^ 
software a^iplication. 
5 IhFig. 1, a schematic view is shown of the execution e»^^ 

plication according to an embodiment of the present invention. The sch em ati c view 
shows three parts of the software plication esoviromneot, tixe deveLopmeat part 1, the 
run-'time execution part 2 and the input/output part 3. 

A sofbvaze application is develop^ acoozding to the present invention nsing a 
1 0 spediication editor 4 to analyse the software application and construct an application 
specification. The specification editor 4 produces tiie ^plication specification 10, e.g. 
in the fonn of a XML file, in a maimer to be discussed below. 

The specification editor 4 may coiaprise a processor 20 with associated memory 
21 and an input/output device 22»asshownsch^naticaliyinHg. 3. Ofcourse^itwillbe 
15 apparent to tiie person skilled in the art that tiie specification editor 4 may be 

implemented using e.g. a computer^ or other processing means and related peripheral 
equipment known in tiie art. i 

Ibe heart of tiie software plication execution is the generic ideation engine 
5, running on a computer system. This generic plication engine 5 provides the 
20 standardised functions whidi may be used by a software ^plication. Jn combination 
with tiie application specification 10, tiie, generic application engine provides the 
behaviour of the software ^p}^^(m, using data residing in a database 6. 

The generic application engine S is connected to a nundsa of possible i nt erfe ces 
for mput and output to a user. A user may be a human nser» using a (gnQdiical) user 
25 intezf^ or a furtiier software or hanlware system using apprt^riatei^^ 

human interfiace may be in^lemented in a varieQr of manners, of i^ch some are 
shown inFig. 1. Awebinteifiice 11 may be used to interact witii the software 
application. Alternatively, a windows interface 12 may be nsied. Both alternatives may 
be used in an Ititemet or Intranet environment, or on astand-^alone OP&based) system. 
30 Otiier user intex£u:es may be &-mail or sms interfaces 1 3, ot even a file inter&oe 14. 

The database 6 ^ch is being used by the software sppfication. comprises data. 
These data may. in addition to bdng usedby the soflwaze application according to ttie 
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piesent mvention, be used for other puzpos6S» using analysis reporting tools IS, 
wliich are known se in the fidd of database processing. 

Hg. 2 shows Oie composition of an i^Uoation specificatioix 10 acconfing to an 
embodiment of the pzesent invention. The ^plication specification 10 comprises at 
S least a regular spedflcation 7, whidi defines the basis of a sofiwape s^Iieation. For 
certain software s^plications, it is conceivable that the application specification 10 only 
comprises a regular specification 7. For other software applications, the ^plication 
specification may comprise a computational specification 8, wbich can include 
\ additional functionality to a software application, such as flow charts, constraints 

« 10 and/or macro's. Finally, die ^plication specification 10 miay coxnpnse an appearance 

i specification 9, which defines application specific elonents of tiie user inter£a^ej 

i The regular specification 7 may be assembled interactively using the spedfication 

^ editor 4. The core of the regular specification is formed by a definition of data classes 

^ and user groups, as well as the roles assigned to the user groups witiireq»^ 

15 classes and th^ fields (see below), expressed hi pennission& 
^ Data classes are groups of objects which play a role in ti&e software plication. 

To design a software plication, the first step is to translate tiie real world item^in a 
model by means of analysis. Una comprises identi^)^ the data classes, normalizing 
the data classes (Lo. delete r^etiti ve gcovps and redundancy) and identifying th€^ 
20 relations betiveen the data classes* 

For the present system and mediod for buildii^ a soflware qiplication, data 
classes are desoibed in the plication specification 10 usmg a numbespEof 
diaracteiistics* such as: 

• aname; 

25 • the name oflfae database and the name ofthe database table whe^ data about a^ 
objects are stored; 
« a parent data class; 

• order in which data classes are shown (if nothing is specified^ data classes will be 
presented in alphabetical order), 

30 • a size of a data dass; 

• a constraint specifying a subset; 

• a primary show field 



21. FEB. 2005 11:21 



NED.OCTROOIBUREAU 31 70 3527528 



NR. 770 



P. 22 



WO2004/02im 



PCr/NLZ003/000«)6 



10 
IS 
20 

25 
30 



By identifying a paient data class (optional), a hieraichical structure of data 
clashes can be defined. The role of this hieraichical structure is described in s^arate 
paragraphs below/ 

For this invention, an important characteristic of the data class is tiie si^e of the 
data class. This is the number of (expected) objects and defemzunes the maimer in 
which die data class is shown to the user. Options are: 'none\ ^small', 'medium* and 
•large'. 

Another main characteristic for the data class is tiie primary show field, which 
has to be one of the fields of the data class. The primary diow field allows an object to 
be discriminated from other objects by a user, better than the technical ^ 
The value in this field will be used as a label in a tree represmtation of an object The 
primary show field is also impoitabt in relations between objects. Suppose that a data 
class A comprises a field F, vMcVt defines a relation to (the key field of) fbieiga class 
B. At runtime there can be an object a of data class A, havisig a relation to an object b 
of data class R This means diat thi& actual value of field F in object a is the value of the 
key field of object b. However, when object a is shown to a human us^, die value of 
the primary show field of object blis shown as the value of fidid F, because this usually 
makes more sense to a humaoi ttian ttie vahie of the (technical) key field of object b. 

jn case of a many-to-many relationstiip between data classes, an intermediary 
data class is specified, and marked as a 'relation class' (also known as an * association 
class' in object oriented modelling. A relation class has no fields, it only has two 
connected classes. Data about objects in a relation class is stored in a ^ccific system 
table, that does not have to be specified. 

Tor each data class categories can be specified. (Categories groi^ data wfaidi are 
related to a data class. This can relate to fields (see below) or other data classes vdiich 
are linked to the current data class. On ou^ut deivices, such as screens, categories may 
be shown as paragraphs, as nodes in a tie^ as separate tab sheets in a collection of tab 
sheets, as indqpendent sa:e6ns, etc. In another fi>im of output (in a text file or on a 
printer) categories can be shown as paragraphs. 

Categories are included in the regular specification 7 with a number of 
characteristics, such as; 
• aname; 

« a content type of the categoiy: 
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• a content class; 

• Older in which cat^ories are shown (if nothing is specified, eateries will be 
presented in alphabetical cider); 

• a presentation type: values may be: 'as paiagr^h', 'in tree', 'on tab* or 'own 
window*. When no presentation type is specified, the generic application engine 
chooses *on tab' as de£mlt 

There are two possible content types: 'fields', which means that the cale^ny 
comprises fields that are associated wifli fee da^ class; or 'connected objects', ^cfa 
means that the category comprises the related objects of a connected data class. 

' A content class has to be specified only when the content type is 'coai^ected 
objects'. The content class specifies fi^om wbicb data class Ihe objects have to be 
selected. As content class can be chosen; a connected class of the current da^ class, or 
a data class that is connected to fee current data class by means of a relation ^lass. In all 
descriptions below, a data class that is connected through a relation class, is handled in 
fee same maimer as a regular connected class. 1 

For each data class a number of fields can be specified. Fields are usedtas fee 
basic ekments for storing data within a software ^licadon. For each field f, 
dbaracteristics may be specified, such as: i 
aname; ^ 
a long label (fee long label being shown when fields are presented one at^each row); 
a short label (fee short label may be used as column header when objects are 
pres»ted in a tabular form); 
a data type, such as string, integer, grc^hic; 

an indication that the field is part of fee technical key, which allows fee unique 
identification of objects; ' 
a description of fee field; 

input instructions for fee field (instructions for inserting or updating values); 
order in which fields are shown (if nothing is specified, fields will be presented in 
alphabetical order); 
a domain (see below); 

a foreign class and, if needed, a foreign field (see below); 
a deduction rule (as a computational specification 8); 
a dynamic lookup Kst (as a computational specification S); 
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• fhe name of the database column whore ihe value of flus field is stoied (ttiis ootuxxm 
should be part of the database table as specified for the cuxxent data class) ; 

• a pazmt field» a fitnction and/or a zelation (see the pazagt^h on fidd bieraxchies 
below) 

5 To define one-to-cme or one-to^nany relatiozisbqis betwem data classes, a field 

may comprise an identificaticm of a fi>teign class. The foreign class has to be one of the 
oth^data classes as described in tfie ^iplicafion spedfication. As aresult» the current 
data class tvill become a connected class of the data class that is specified as flie foreign 
class* A foreign field might be specified too. When no foreign field is specified 

10 explicitly, the primary key field of the foreign class is fhe foreign field implicitly. Tbjs 
foreign field of the objects ofithe foreign class holds die possible values for the current 
field. Such a mechanism is usually known as a 'foreign key constrainf or 'referential 
integrity*. The kind of relatiohship (one-to-one or one-to-many) is spedfied by 
specifying the multiplidly. i 

IS In addition to the above-mentioned cbaracterisdcs, for each field, its role in ihe 

user interaction can be speci&d, e.g.: 

• It can be specified whether the field can be used for creating selection criteria when 
searching or selecting objects fiom the data class. A field can set to be a 'primary 
selecticm fields which means that the field is shown dkeotly to be used in selection 

20 criteria when seaznhix^ for objects of the data class. A field can set to be a 

'secondary selection field! when Ihe field can be chosm fiom a pick list in second 
instance before ^c«i be used for creating selection criteriaL 

• The field can be linked to a category. The category must be one of the categories of 
the cuzxent data class, or a de&ult category. 

25 • It can be specified whether die field will be shown as a column whm flie objects of 
the data class are rq)resented m a table. 

• It can be ^edfied whedier the field can be used in a cross table representation, 
including the role: as coliunns, as rows, or as cell content* 

A unique feature of this invention is the powerful usage of hierarchies in the 
30 application specification and in the generic s^Iication engine. In fiie plication 
specification, two types of hi^archies mig^t be used: class hierardhies and field 
hierarchies. Class hierarchies arise as soon as a data class is set as a parent of another 
data class, making the other data class a child fiom the first one« In the remaining, the 
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pdieot is called 'super class*, fhe child is called 'extended class\ Field hierarchies arise 
as soon as a field is set as a paxent of another field, makiog 1h& other fidd a child from 
the first one. In the remainiiifc the parent is called 'sixpct field, the duldis called 
'extended field'. 

The main advantage of ysing class faiexarchies is inheritance (similar to the usage 
of class hierardiies in Unified Modeling Language). In the system and mediod 
according to the present invention, all single characteristics of a super class are 
inherited by the CKtended class, except for the unique id and the name. Howeva, all 
characteristics can be overwritten in the extended class; unique id and name are always 
overwritten* ' * 

In addition to the standard usage of inheritance^ this inv^tion intcoduces some 
new features of class hierarchies: i 

a. First, in tiie extended class, it can be specified explicitly: 

• whether or not to inherit all fields from the super automatically 

• whether or not to inherit only specific fields from tbue stqi^ iiatomatically (e^g. 
only the fields that can be used in selection criteria or tiie fi^ds that are shown 
as a column when objects are represented in a table) i 

When fields are inh^ted automatically, tiiese fields are called the 'inherited' fields 
of the extended class. ^ 

b. As described earlier, fi>r each data class anumber of fields can be specified. Tliese 
fields are called the 'declared' fields. Declared fields 'belong* to that data class. An 
extended class can also have declared fields. The totat^f inherited fields and 
declared fields is called 'associated fields' or just 'fields'. 

c. As a result; extended classes can have two types of fields: mherited fields and 
declared fields. The genoic application engine will combine ihe inherited fields and 
the declared fidds for each extended class, and position them according to their 
presentation order. 

d. Inherited fields inherit all chaiacteristios of their ancestors in the siqjer class. These 
characteristics can not be changed in the extended diass. If a modification is needed, 
own fields have to be declared for the extended class (declared fields). 

e. An extended class can be assodated with a definition of a subs^ of objects of the 
parent class. If a subset is ^ecified, the objects in tbis extended class are always the 
specified subset of objects of theparrat class. 
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The above meaticmed aspects of class bierarchies in the present invention incieases fhe 
specification power of the generic ^plication engine, and allow for &5ter development 
and eader maintenance of applications. 

One advanta^ of using field hierarcliies is inheritance. In flie system and method 
5 accoiding to flie piesent invention, an extended field inh^ts all sin^e characteristics of 
its super field» except for flie uniq[ue id and the name. However, some characteristics 
can be overwritten in the extended class; unique id and name are always oveatwritten.^' 

A field can use almost every other field specified elsewhere in fiie q)p]ication 
specification, as a si^er^ field. 
10 a. Tlie super field can be selected fiom the fields of the sq)er class of tiiie data class of 
the extended field (only when this data class has asvp^ class)* 

b. Hie super field can be selected fiom the fields of any other data class in the 
application specification. 

c. Usually, it makes no;sense to let the super field be selected £com ibe fields of the 
15 data class of the extended field. Thmfore, this situation is not described h^e. 

Domains may be defined sq»arately in the application specification. Domains 
comprise allowed values &r fields. £.g. a day indication of a date field will be limited 
to fixe values 1-3 1. A domain may be valid for multiple fidids^ For each domain an 
int^al type has to be specified. An interval type may be ^ot GrdCKed^ ^discrete' or 

20 'continuous* . The values in a domam having a ^ot ordered* interval type, have no 
mutual relationship. This is usually the case in ^string* type data, e.g. Taris', "London', 
'Berlin'. The values in a domain havmg a 'discrete' interval type have a mutual 
oideting, e.g. 'l:bad', '2mediate', 3:good\ Note tiiat each domain value can con^irise a^ 
key, such as ' r and a label such as *bad'. Hie set of keys contain fixe allowed values 

25 for the field in actual obj ects. The label specifies the value as it will be presented to tixe 
human user. A ^continuous' interval type is like a ^discrete' interval type, but tiie 
domain is only used in select actions, not in modification actions. This means that tiie 
actual values of the fields in fhe objects are continuous. E.g. when the values in a 
domain wifii a 'continuous' intenral type are '0:at the beadi', Ul xlose to the beach', 

30 'l.Omot fin: finom die beach*, the actual values of objects could be e.g. 0.2 or 0.8. 
Howev^, usees use the labels (e.g. *at die beach*) in select actions, instead of the 
numbers. 
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When a select action i$ perfozmcd with selection cxiteria containing a field with a 
disciete domain or a continaou$ domain (both are refened to hereinafter as 'oideced 
domain'), the selection i$ per&xmed in two steps. In a first step die criteria vdlh a ^not 
ordered' domain are applied first, lesultix^ in a subset of objects. In a second st^ the 
5 resdting subset is ordered by a score. For each object this score is (a fiinction oQ the 
distance h&tweea the desired value in the selection ^t^on foft the field tfiat has die 
ordered domain, and the actual value of the field of tiie olgect If more than one field 
widi an ordered domain is involved in the selection criteda, %^ total score for each 
object, win be the total of the individual scores for the fields, i 
10 User groups are groups of us^ (actual persons using a (graphical) user inter&ce) 

or other softwaie applications or hardware systems, which share the same petmissions 
rel^g to data classes. User groups may also be modelled using hierarddcal 
relationships (child-paient relations). Child user groups iohedtt die permissions of their 
parent user group. 

1 S Individual users of the software application are always laipwn to the generic 

application engine as regular objects of a regular data class. Thk class is called the 
'user class'. The object representing the user (data) is called the^'user object*. 

Pennissions, in the form of grants or authorisations, speci:^ what a certain user 
group is able to do with cettain data (and thus implicitly what they are not allowed). 

20 Pemiissions are stored in the regular specification 7 using peranssion matrices. 
Pemiissions m^ include: i 

• select pennission: specifies whedier a user group is.allowed to select objects of a 
data class, possibly also ^ch fields may be used lEbr fiie $el6ctio£^ 

• export permissioxi: specifies wheffaer a uso: group is allowed to expcnt data about 
25 objects of a data class to file, possibly also which fields maybe exported; 

• read pennission: specifies Aether a user ffoap may read objects of a data class, 
possibly also which fidds can be read; 

• update permission: ^ecifies whether a user groi^ may update objects of a data 
class, possibly also which fields may be updated; 

30 • SQsert permission: specifies whether a user group may insert new objects to a data 
class, or on field level, which fields may be entered in a new object Once the object 
is stored, a new access to the object is governed by the update pennission; 
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• copy pezxnissiou: specifies whettier a user gcoup may copy objects of a data class, 
and store the copy in the datatbase; 

• delete pemiiasiOKU specifies whether a user groiq) may delete objects of a data class. 

On data class level all above mentioned penmssions can be specified. On field 
S level only the first five pemiissioiis can be specified. If a pemoission is spedfied on 
field level, this always ovemiles tfie specified permission on data class leved. 

The permissions in the peanission matrices caa have one of the fbllowmg values: 

• no: &e user group does not have the pennission for (b» data class or the field; 

• yes: the u$er gr<»q> does have the pemiission for the data class or the field; 

10 • 'follow foreign object* (ffo): the pCTiission is depend^t on the pennission which is 
valid for the cuzrent foreign ol:!jecL The current foreign object is the last object that 
was selected by the user on the route to the current obj ect (more fidrmaUy, it is the 
object that was last added to the context, see below). The value ^fib' may be usefiil 
in the case of multiple &cts which may be considered as &cts of a data class, but 

IS for which (for reibons of nomialisation) a coonected class has been created, e.g. 
wfaen^ e-mailladdresses of a person have been grouped in a separate data class 
haviz^ fields *typte' and 'address'* Wh^ a road pennission has the vahie ffo'> at lun 
time the geneodc plication engme uses the value which is valid fi>r fte read 
pennission of the fiiieign object V^ea an updaSi^ insert, copy or delete peimissidn 

20 has the value '£&f , the generic ^pUcafion engine uses the corresponding value fiir 
tbi^ update pennission of the fbteiga object 'fifo* can not be specified fix a select or 
cgqwrt permisKion, 

• own: die pennissioa depmds on ndadons between the curmt user object and the 
current data object The cuxtent data obj ect is the object that is (going to be) read 

25 fimn a database 6n case ofa select p«mussion) or is already 

application Qn case of the other peraiissions). When 'own* is chosen as value, also 
the r6latLonship(s) that express the 'own' relation have to be specified. E.g. die 
*own* relation might be expressed as a direct relation fiom the user class to die 
cuzient data class. In another case, both the user class and the current data class 

30 mi^ have a rdadon to die same foreign class. All odier relationships between 
classes can be used in the specification of the 'own' relation too. The generic 
q)plication engine grants the cuzrent user the pennission when the us^ object and 
the current data object actually are related according to the specified xelationship(8). 
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• constiaint: the pennissiCQ is governed by a specific constraint: for all objects for 
which the constraint is met, the pomission is "yes*, for the oth^ it is W. The 
constndnt is defined in another part of the application specification^ the 
computational specification 8 (see below). 

The combination of these five pennission values is a unique feature of this invention 
and allows for faster development and easier maintenance of software appIicatioDJs. 

One of the last steps m creating the regular specification is adding other basic 
functioiiality, e,g. user authentication, sending e-mails, registcaring incoming e-mails, 
etc. Hiis is done by mi?)ping tiie standard built-m functionality of the generic 
^plication engine to the relevant fields of ttie data model (e.g: the fields where user 
name and password are stored, respectively the e-mail field). ISx the area of component 
based development, this is known as *deploynient\ ^ 

The computational specification 8, adding additional fimc^tionality to the software 
^plication, may comprise sequOTces, conditions and/or itejatiOns. Thoe are three 
kinds of computational specifications: t 

• Flow chart a flow diart is a structured manner to describe liow the value of a 
variable may be deduced. Using ^quences, conditions and^iterations, the steps for 
detennming the vahxe of a variable are descnbed Each flow €^ 
deieraaination of tiie value of one or tnore variables (tiie ouQmt variables). A flow 
(to may be used to speofy how a vahie of a fidd can be deduced fiom oth^ da^ 
like (other fields of) the cuzxent object, die context (see beldw) or the user object A 
flow chart may also be nsed to specify how data nfodifications may be validated; 

• Constraints: a constraint is an expression \^iich may be used to pose an additional 
restriction on objects of a data class. SwUx a constraint posed on a data class will 
lesult in a subset of all objects of tfiat data class. A constraint nuiy comprise 
multiple constraints combined by Boolean operators. A constiaint can be used to 
specify how the content of a lookup list may be deduced dynamically, dq)ending on 
the actual data and the user object A second usage of a constraint can be the 
specification of a permission rule tiiat can not be described in a matrix 
representation. Here again, the actual data and dxe user object can be used in the 
constraint specification; 

• Maoo's: a macro is a collection of statements which may be executed in sequence, 
possibly accompanied by process logic (conditions and iterations). Amacxo may be 
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executed in response to an action on an object Then it is also called a trigger. 
TriggGK$ may be defined when cheating an otg ec^ when rdrieving an object fiom a 
database^ ^^vbsa updating a value of an object within the software plication, when 
inserting, deleting or updating an otgect in a database^ or when exporting an object 
to file. A macro may also be ^ecuted on request fiom a user. 
The main goal of the ^roach described here is to minimize the need fer 
computational specifications, and maximize the poi^lnHties of r^ular specifications. 
However, tiie gen^c application engine can be extended, whoi other types of 
couq>utatioDal specifications are needed. 

One of the key el ements of the currrat invention is the fact tSbat fiom the 
plication specification as described above, the genoic a|)plication engine 5 is able to 
construct all interfaces^ windows and screens that are used by users for interacting with 
the software ^plication and its data. la the following, a description is given how the 
generic q>plication engine 5 deduces the screens for user interaction fiom the 
^plication specification. A similar mechanism may be used for the program-to- 
progcam intofaoe or for the output to text files or printers. Please note that in the 
previous paragr^hs, some parts of the mechanism are already described. These parts 
are not lepeated^in the fi)IIowing. 

In ttie cunent invention the geoBric ai^tication engine uses read^toHosebuildiog 
blocks. The basip buildii^ block of a software i^lication is a class manager. A class 
manager provides flte functionality to present the objects fiom a data class in a simple^ 
tree and/pr tabular representation* to allow a user to select objects fiom tiie specific data 
class, to present.tibe details of an object and to modify objects. While updating values 
of objects, default values, input mstnictions, input aids and/or ixqiut validations can be 
qjplied. 

A uso- can have direct access to all class managers fi>r data classes he/she has 
select permission to. From tiie first class manager other class managers can be reached 
by hyperlinks or buttons. 

A class manager always has one corresponding data class, called die *main class' . 
Besides objects fix>m the main class, it can hold data fiom otiier data classes too. These 
other data classes are always (indirect) connected classes of the main class, specified 
with means of categories of content type ^connected objects'. 
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The size of the main class det^mines how the class mana^ presets objects on 
a SGK&L When &e size of the main class is "nonc^y tbten ttie data class contains no 
objects or fields, but only rdations to connected classes by its categories. When the size 
of the main class is 'small', fhe class manager shows a tree at the left side of the screen. 
The top node of the tree will have a label like 'All.objects'. As child nodes, all objects 
of the data class are xcpresented (with respect to read peimissions) by flicur value of the 
primary show field When tibie size of a data class is "medium' or 'large', objects can only 
be found by searching. When fhe user selects such a data class, fhe class manager 
presents a screen to enter selection criteria. These selection criteria have to be 
constmcted from the associated fields of fhe data class that are mariced as a (primary or 
secondary) selection field. After zpplymg these cntmz^ tiie objects IhsX meet these 
criteria will be presented in a tableland from there, the d^ails of each object can be 
accessed. 6.g* by selecting a row and/or activadng a buttcm. The details will be shown 
iix anew window. In a web inter&ce, Ibis can also be anewpage in thecuttent web 
browser (this also holds for fhe remaining of this description). 

AUoy the pieseotation type of a category as defined in fhe application 
specification detennines the pres^tion. When at least cm of the categories of a data 
class has fhe presentation type 'in tree', the generic application engme will show a tree 
on the left side of fhe screo. There are the following options: 

• The main dass has size 'smaU\Bi this case, there alr^y is a as desci^^ 
eariter. 

• The main class has size Medium' or 'large. Jhis case tiie uppemiost node in flie 
tree is the value of the primazy show field of fhe cutnent object. 

• The main class has size *none\ hi this case the JippeoDOSt node in tibe tree is fhe 
name of fhe data dass. 

Whenever a node, rq)ieseQtiag an object (or tiie data class with size 
selected, details are shown on the right side of tiie sciew: fiist Aie fields of fhe de&nlt 
category, followed by the categories that have to be presented as paragr^hs, followed 
by tab pands for each category which have to be presented on tabs. Hie presentatioa of 
a category itself deprads on its content type. When the content type is 'fields*, the 
fields associated with fhe category arc shown, one at a row. The generic application 
engine will position them according to flieir presentation order. Each row starts with the 
long label of the field, followed by the value. When fhe content type is 'connected 
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objects*, a table wiU be shown with arow for every rdevant object The generic 
application engine will continuously check permissions, and will never diow fields, 
cohnnns or cells that the current user is not entlfled to see. 

The categories with presmtatlon type % tree', win be shown as sqiarate nodes 
5 under the nodes diat are lepzeseuting an obj ect (or the data dass with size •none*)- The 
name of the category will be used as label. 

• Selecting a node that represents a category with content type 'fields*, will show the 
fields of the category on the rig^ side of the soreen. 

• Selecting a node that represents a category with content ^connected objects* 

10 will i^ult in an empty xi^t side of the screea However as child nodes of this node, 
the user will find all related olgects &om the connected class as sq)drate nodes. For 
all thdse objects, the same may be repeated. 
When there is xU) tree representation (there is no data class with size 'small* » and diere 
is no category wift presentatioxi type 'in tree*), all categories will be presented in the 
1 5 same manner as described above. 

Categories wi& presratadon type 'own window* can be reached by activating a 
button. The content win be presented in another window. 

Th6 chaiacteristics of the field may also influence the presentation on the sck&l 
The lon^labdi of a field may be shown in fiont of the field value, as well aa a possible 
20 descrq>tion (e^g, as a tool t^) or a possible input instruction. The data type of a field 
determines the associated screm object When a domain or a fordgn class is specified, 
the field is usually represented using a loolciq> list When tfie size of a foreign class is 
'large', only tiie current value of the field is ^own, accon^ianied by a button or link 
that brings flte user to a search screen aUowing to select a new object fiom the fbrelgn 
2 5 class. As current valuer the generic plication en^ne uses the value of die primary 
^ow field. 

From every row in a table rq}re$entation» the user can visit att details finom the 
data in that row, e.g. by selecting a row and/or activatij^g a button. The details wlU be 
shown in a new window. When a field or table ceU comprises a reference to a foreign 
30 object, this is automatically represented using a hyperlink, linkine to the details of that 
object These hyperlinks are only shown when the user has read permission on the 
foreign object 
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Also, pennissioxis det^mine the ^ipearance of the software aiiplicaiion. 
Depending on penxiissioiis of the current user, some (select) field$) or columns in tables 
will be shown and others not Penuissions are also ^qiUed on all objects and actions on 
object$. Rg. insert, delete, copy, or save buttons will show or hide automticaUy, 

5 accoiding to the petmissions. Fields and/or table cells axe only editable when tiie user 
has update oq. insert pemussions on the cuncent obj ecL 

The generic 2q)pIicatLon atgine handles field inheritance as £bllow8. In case of 
situation a (as described in the field inheritance paragr^h), at runtime die extoded 
fields are considered to be fields of flie esctended class. Ihte generic ^plicatioxi engine 

10 fi^pUes all inheritance rules automatically and the application will bdiave as if the 
extended field is a regular declared field. If an e?ctended class contains both inherited 
fields and extended fields, there might be an extended field that extends fiom an 
inherited field. In this case, the generic application engbie removes the inherited field 
fiom the ext^ded class. A shxq)le example illustrates this sitoatioiL Suppose you have 

IS a data class A wiih fields: i 

• al (with presentation order 1) , t 

• a2 (with presentation ozd^ 2) and f 
9 a3 (with presentation order 3). * 

Suppose you have another data class B, with data class A as sap&: class. Data class B 
20 inherits all fields fipom data class A and has two declared fields of its own: 

• bl (with presentation order 4 and without a suqper field)» and 

• b2 (widiout a presentation order and with a2 as super field). 
Runtime this leads to the fi)Uowixig Older of fields for data class B: 

• al 

25 * b2 (does not hdifirit filename^ but does inherit the presentation ox^ 

• a3 

• bl 

Note that in the case of situation a the behavior of the application could have been 
obtained without the use of field hierarchies. In this case, field hierarchies only allow 
30 fi>r fester development and easiqr maintenance of applications. It is a very 

advantageous that it is no longer needed to specify all fields of data classes completely. 
Now they can be inherited and/or extended in difiieient ways. 
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In case of situadon b (as described in the field iiih^tance paragn^), at runtixDe 
the e3ctmd6d fields aie shown onoatput devices, such as scce^ and reports, to be 
fields of the eactraded class, bat in the background ttiey are not In tiie background, Oie 
fields belong to different data classes, that are intenelated. Hiar^ore the generic 

S qyplication engine should know v^di ieIationshq> has to be emptied between the 
cunent data class and fiie data class where the soptx field is decIaredL When no fiirther 
spedfications axe given* the generic i^licafion engine tries to find die shortest (direct 
or indirect) applicable relation between the current data class and the data class where 
the si^er field is dedared How this is done exactly is not described here, since this 

10 wiU be iq>paieiit to the person skilled in Ifae art IVhen no suc^ 

found uniquely, the applicable relation has to be specified in the application 
spedfication cxplidtly. The ^plicable relation is used ui the following ways. 
« When the extended fidd is used for seardiing &r objects, the relation is used to 
define additional constraints to ttie database query, usually usmg different tables 

1 S (conform common relational database theory). 

• When the e>cteoded field is used for displaying data of objects in a table, tiie relation 
is used to create a join between objects of the currmt data class and objects of the 
data class where the super field is declared (conform common relational database 
fiieory). As a result fix>m the join, the table mi^ show more rows fiien there are 

20 objects in the current data class. 

« When the extended field is used for displaying details of a single object, the relation 
. , is used to create a join for all extended fields wifii a siq)er field that belong to a 

fordgn class. When tibe super fidds belongs to a connected class, a fimctionhas to 
be ^edfied also, like count, sum, avtfage^ max, miiL The generic q)plication 
25 engine s^Iies this fimction on aU connected dQ'eds on the values of the super 
field. 

Note that a sixsple join with connected objects is not possible^ because this mi£^t 
result in more than one record. For a relation to comiected objects, a functioa is 
always needed. For more complex relations between data classes, more complex 
30 mechanisms are needed, but fliese can be induced fi:om die description so 
win not be described here. 

• When the extended field is used for updating data, the U5«r should be aware of the 
&ct thiat he/she is not updating data of the current object, but iq)dating data of one 
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or more related objects. Updating an extended field, means i^dating dala of rdated 
objects {fliis can be foreign or connected otgects or even objects with an indirect 
relation to the cuxreot object). In case of connected objects^ updating a field, means 



• Wben flie extended fidd is used for inserting objects in a database^ the relation is 
used to create relations betwe^ the objects and store the$e relations in the database 
togedier with the objects (confonn common relational database theory). Usually, 
there is one main object, and one or more related objects (foreiga) connected or 
indirecfly related objects). In case of extttided fields wiflx a super field that belong 
to the same connected class, the generic application engine assumes that all fields 
belong to the same object. From every connected class oao object will be inserted 
(as long as field vahxes are provided by the user). It is appansnt that ftis pt^hiu%\ss^ 
can be extended, to create more connecfed objects simultaneously. 
Note that in the case of situation b, the behavior of the ^plicafion could not have been 
obtained without usage of field hierarchies, %r another medianism. Xn Ibis case tins 
mechanism allows fyr specification and mamtenance of powexful, user-fiiendly 
^plications, without the need for piogcamxmng or screen design, lliis is one of the 
unique features of ^ invention. * 

When an inherited fidd of an extended class is part of a category (that is declared 
in the super class), as a result ttus category is inherited automatically by Oye extended 
class. Hiis leads to 'inherited categories'. However, in tfae extended class, categories 
can be declared too. These ere caUed •declared' categories. The generic appfication 
engine will cixaibine the inherited categories and the declared categories &r data 
class, and position them accoidmg to thdr presentation order. If an extended field 
inhmts a section fiom its par»t fidd, the genmc appKcati^^ 
mechanism. 

When a data class inherits fields, whichhsppento be foreign fields, and therefore 
make up one or more relations to one or more connected classes, as a result this data 
class inhoits fliese relations too. When a data class has extended fields witti sixp^ 
fields which happen to be foreign fields, and thoefore make up one or mor^ relations to 
one or more connected classes, as a result this data class inhibits tiiiese relations too. 

Here are two examples that illustrates how ttxe generic application engine uses 
class hierarchies in the runnhig application (without field hiaaichies). 



updating the vahies of all coimected objects. 
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A) luheritaace of eonnected classes 

Two classes in aa i^lication specification both might have the same connected 
class. Kg. the class person axid ibfi class organization bofli have flie class address as 
a coimected class. This can be realized as folloivs: 
5 I. Specify a super class for bo& person and organization^ i.e. actor. This data 
class does not need a database table. 

2. ilctor needs one field, that is flie key field Define a database sequence and a 
database column fortius field. 

3. Make the data class aJdlreji; a connected class of acfor. 
10 4. Inp^onaiidc/^ganjz^dR, inherit aU fields fiomtlxe^ 

is just the key field). As a resoIt> the relation to address is inhmted 
automatically. 

• Botii data class person and data class organization now have a connected class 
address. In the database all addresses are stored in one datab ase table» but every 
15 ' address has a unique relation to a peison or an organization. 

B) vieTvs 

In some cases you want to use a subset ofobjects from a class, e.g. for easy 
f r^eval of your data or for lookup lists. This can be realised as follows: 
j 1. First, create a constraint that specifies the subset 
20 , 2. Next, define a new data class and set &eodguial data class as siqper class, 
data class does not need a database table. 

3. Inherit all fields. 

4. Set the constraint on this new data class. 

Now file genmc ^plication ogine always presents users of fiiis extended class 
25 only the objects that meet tbe constrain^ eifiier in a class manag^or in a lookup 
list 

Hero are three examples of how the g»eric plication mgine uses field 
hierardiies (without class hienffdiies). 
A) using extended fields for isdecting objects 
30 In some cases, users mi^^t want to search fin: objects in the database, not only on 
their own fields but also on one or more fields of related objects (foreign objects or 
connected olgects). This can be realized as follows: 
1. Declare a new field in the currrat data class. 
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2. Set the field from fliefordgD or cotmected class 

3. Specify the new fidd as a selection field (either as pzimaiy solecdoa field or 
secondary selection fidd). 

Now a user can also select objects that have a relation to one or more other objects 
5 that meets a certain constraint 

B) using extraded fields for presenting objects in tables 

In some cases, users might want to see obj ects fiom the database in tables^ with as 
columns not only their own fields but also one or more fields of related objects 
(foreign objects or connected objects), Ttus can be realized as follows: 
10 1. Declare a new field ui the cuirent data class. 

2. Set the field fiom the foreign or connected class as 3\xper field 

3. Specify the new field to be pres^ted as column in a table. 

Now tables contain not only the own fields of a data class» but also fields of related 
classes. 

IS Q using extended fields in presenting details of objects 

In some cases, users might want to see details of a single object, with as fields not 

only thdr own fields but also one or more fields of related objects (foreign objects 

or connected objects). This can be realized as follows: 

I. Declare a new field in tibjecunent data class. 
20 2. Set the field fix)m file fordgn or conniocted class as si;per fidd. 

3. When the si^er belongs to a connected class^ also a fimction has to be qiecified. 

The generic plication engine will now also show additional data by exteavled 

fields. 

Finally, two examples on how the generic plication eng^e handles tiie 
25 oombinafion of class hierarchies and. field bimrdues. 
A) insert only forms 

Class bierarchies also aUow easy specification of special fomiis that are only used 
for data entry. These also include fonns that are used on the Intiemet, e.g. for a 
request for infoimation or ordering a product Tbese forms can be realized as 
30 follows: 

U Spedfy the form as a new data class. This data class does not need a database 
table. 
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2. Sdect the data cla^ where most ofOie data oflbefimn belongs to, ^ 

this the super class £or the new fona 

3. Hdia inherit aU fields from the si^er class or declare the fields for the fonn. 
Every declared field has to be an extended field, it needs to have a super field 
Usually, the si^er field is a field fiom the siq)er class, or a field fiom a 
oomiected or finrdgn class of ttie super class, but it oiigbt also bea field fit>m 
another class. In case no dppUcsd>le relation can be calculated automatically, 
the applicable relation has to be specified etKpUcitly. 

The goieiic q)plication engme will take care that all data will be uiserted m the 
right tables in the database. The relations between objects are cteated antomattcally. 
This allows for single fonns where data for several tables can be enteied. 
B) joins: emalatibag a many-to-many relation 

hi some cases, users of the application do not have to know that among the data 
classes, there are one or more intermediary classes, needed to implemwt logically 
many-toHnany relatioiis. These intermediary classes can be bidden as follows; 

1 . Define a new data class. This class does not need a database table. 

2. Make one of the ends of the many-to-many relation (say the left end) the super 
class and inherit all fields, 

3. Manually declare extended fields for all the fields in the intermediary dass 
(every field in the intezmediaiy class has to be a super field once). 

4. In fiict this defines a classic view (by a classic join). This new class can be used 
as connected class hi a category of the class at the right hand of die relation. 

Example: suppose diere is a many-to-many relation between Che class person and 
the class organization. Therefore an extra class relation has been created. By 
defining a join on organization and relation^ details of the organization can be 
shown directly as connected objects of a peraon. If desirable, fiiis view is 
updateable automatically. 
As described above, fiie generic application engine automatically derives a 
presentation for all data and actions. However, all usos are allowed to change die 
presentation, according to dieu: own preferences. At runtime, fiiey can sort tables^ fiiey 
can change the order of fields, diey can change the presentation type of categories, they 
can hide or show columns in tables, etc., all with respect to the specified permissions. 
All modifications of the presentation can be stored for re-use. 
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In summery, after eaterixig an application specification into the g^ieric 
^plication engine, a software application is created that allow useis to select (seardi), 
read (fiom simplci, tree and/or tab representations), restnictuie (sort, join) and modify 
Qx^sext, copy, delete and update) all data in ttie software plication, exactly according 
5 to the user's pcnnissions. This functionality is provided in a web inter&ce (SThSL) 
and/or in a windows inter&ce. 

Using a web inter&ce, the qipearance of the software application may be adopted 
to Che user's need by using an appearance specification 9. Hie generic application 
engjne creates all screens to be di^layed to tiie user as XML documents (extended 

10 Mark-up Language). These XML dbcinnenis may be transfonned to HTML 
^yperText Mark-up Language) using a XSl>document (extensible Style sheet 
Language) and/or CSS (cascading style sheets). With XSL, screen objects may be 
positioned or rq)laced and with CSS layout characteristics may be changed, such as 
background, colour and/or font 

IS The plication specification may comprise a lot of other characteristics, which 

might be relevant for the actual realisation of the generic ^plication engine, but, as 
such* these are not new and already known in the area of data processing. They are 
omittied fiom ibis description^ since they will be apparent to the peiaon skilled in the 
art 

20 Ihtemally, every time a dass manager is called from another class manager a 

oont^t is passed, A context contains an ordered list of all objects i9i4iich wet« passed 
by the user Qn several class managers) to aiiive at the present class manager ftom the 
starting point of die software application. Also the relations between the objects are 
stored in die context 

25 When a class manager is also holding data for connected classes, the current 

object of the main class (the 'main object') is also added to the context for all 
operations on objects of the connected classes. Also tfie relation fiom die cunut main 
object to flie current connected object is added to the context. 

When the class manager also holds objects of indirect connected classes, all 
30 intermediary objects and relations are also added to the context, for all operations on 
the objects of the indirect connected classes. 

The usermay deddes to switdlto anotiier class manager, which shows details of 
an object or shows a category widi presratation type *own window'. In these cases the 
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context as constmcted so far (with the list of obj eots and relations) is passed to the next 
class manager. 

A class manage may use a context in di£fermt ways. Fiist» a context can be used 
to ^ly additional constcaints on objects (6.g. only showing objects which are valid 
i widiin the preset context). Jn older to define whether an object fimn a data class meets 
die constraints defixied by a context, first all relations fiom this data class as connected 
class (modtiplici^ *) to the data classes in the context as foreign class (multiplicEty 0.. 1 ) 
have to be listed (according to the application specification). An otgect meets the 
constraints, only if fyr all these relationships, there actually is a relation fiom this 
object to die objects in tbe context lliis mechanism is s^pKed when adass manager 
shows the connected objects of an object in a table or tree. 

The cont^t can also be used to qjply ad(fitional constraints on tookup lists which 
are constructed fiora objects of a foreign class. In this case osaly a subset of all objects 
from the foreigu dass are shown as options, only those that are valid within the present 
1 S context. The same rule as above is applied to define whether an object meets the 
constraints defined by a context 

Furthennore, the context can be used for adding default values for newly defined 
objects. In tins case the class manager will add relations to the objects m the contact 
automatically, as far as there are relations ^ecified fiom the data class of the new 
20 object as connected class (multiplicity *) to tiic data classes of the obj ects in the context 
as foreign class (multiplicity 0..1). 

In the apphcation spedfication it can be defined whether the conteia has to 
^plied (or not) in all above cases. 

Fmally, a context can be used in the execution of computational specifications^ 

25 such as infisrence rules or pennission rules. 

The foundation of the generic plication engme is the subject of patent 
qiplication PCr/NLOl/00926 of the inventors of tius patent application, which is 
incoiporated herein by ref^ce. In patent application PCT/NLOl/00926, the tcnn 
'configuration* is used whidi coitesponds to tibe term 'ai^fication specification' as 

30 used in the present patent application. The tcnn •entity* iiiPCTyNLOl/00926 

coiresponds to the tenn 'data class' as used in the present patent plication; die temi 
^attribute' m PCT/NLOl/00926 corresponds to the tenn 'field* as used in die present 
patent q>pUcation. The 'object search* and 'object editor* fimctionalities as described 
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in PCT/NLOl/00926, are integrated in the 'class manager'. A 'context' is now 
undaslood to comprise an oideired list of all objects which were passed by the user to 
arrive at ttie present object (via several class managers), plus the indication of the 
rdationships between the objects. 
S For the technical implementation of the generic q>plication ^gine, two strategies 

can be chosen: 

• Strata 1 is interpretation. In this case the ^^lication specification is loaded into the 
goieric plication engine. The generic i^lication engine inteiprets the content of the 
application specification, and khows the desired behaviour to the outside world. 
10 « Strategy 2 is con^ilation. hi this case die application specificadon is loaded into the 
generic application engine. The generic application ragine first reads the cmfeent of the 
application spedfioation, and compiles (parts of) the application spedfication to 
executable program code, d^at win run together with standard compraents of the genoic 
application engine. 

15 The pros and cons of these strategies are well known in the field op data ptocesshig, and 
therefore not further described m this document. 

An example of fiie present system and method for building a software application 
is given below. The example shows how to develop a leseivation iq[yplication fbr 
(holiday) house rentals, in vAmii private home owners offor ttteir homes via a local 

20 agmt The software application has to si^ipoit this viathe InteroeL 

The software qypHcation is realised using the specification editor 4. First, flic 
software application is given a name, and some general characteristics are given, hi a 
second step» the data classes are specified. From an infbnnatioa analysis, the following 
data classes are found in the rental precess: 

25 • Homes 

Data concerning the homes, such as flie address, number of persons allowed, a picture, 
the owner, etc. 
» Rentals 

Data conceniing flie rental p^ods during which the home is avaUablp, as well as the 
rental cost and whedier ttie home is rented during a specific period. 
Persons 

Data related to die various actor$ in the process. These inchide name and address data, 
but also role indication, user names and passwords. 



30 
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The next step is to specify the fields and domains of the various data classes. For 
eadi fields a name, data type, desmptLon, input instructions and domain or foreign class 
(wh» relevant) is indicated. Then, for each data class, the following is specified; the 
mutual order of the fields^ the primaiy show field, iiirihich fields can be used as primary 
(P) or secondary (S) selection criteria, which fields must be shown in a table after a 
select action, which fields are used for sorting the table (ascending or descending), 
^^^lich fields are mandatory, and in which categories the fields must be presented. 

For the daia class "Homes' this results in the foUowiixg entry in the regular 
specification 7. Note that not all field characteristics are shown. 
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llefeence number' is indicated as the raique key field, 'Name' as primary show 
fidd The fields Trice starting from' and Tel. agenf ai« deduced fields, whidi are 
deduced using a computational specification 8. 

The domain 'Countries compzises all relevant countries. e.g.; 
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NA 


Naimbja 


BR 


Brazil 



10 



15 



20 



The domain *Price' is a continiious domain, like *500, dbeap% *1000, average' 
and nsOO, expensive'. This provides the possibility to let users aeate sdecticm criteria 
based on the tfaxee labels, but presenting all results, oidered on the closeziess of the 
match- 
In the field 'Agent' a dynamic lookiq> is defined a$ a computational spedficatioD, 

as it is meant that onfy agents are du>wn whidi have mdicated 
country. 

For the data class 'Homes* four categories with content typo 'fields' are 
specified: •Core data', 'Add. info', *Address^ and 'Contact data'. Fmthcnnore one 
category 'Rentals* is specified. This category has content type 'connected objects' and 
^Rentals' as content dass. As a result, all rentals related to ahome, will be presented in 
a table on a tab panel 

As a next step, user groups are specified. From a further analysis of the actors, the 
following user groins aie identified: 
9 Customers 

• Owners 

• Agents 

• Manager 

As the next 8tq>, flie permissions for usct groups and data classes are specified. 
(Export and copy p^nnissions are omitted in tins exanqile.) 
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legend: 
Y=yes 
N-no 

F " follow fomga object 
C — constraint 

For ttie user group 'Customers' it is indicated that they are allowed to select 

objects &om the data class "Homes' and that they axe allowed to view data related to 

these objects. On field level it maybe indicated which fields fiom these data classes 

they are not allowed to use as a selection criterion or which they are not allowed to 

view. Customers are not allowed to see homes in the database v/iaxAi are matted 

'screened off. This is qtecified in a con^utatioiial specification in ibb fyaa of a 

constraint As a consequence, customers are also not allowed to read rentals idbted to 

15 ^e homes that are screened o£ This is expressed by a feUowfbredgQ object perm^ 

value. Custtmien may also insert xes6rrations.Custoni6is may also inseic^ read and 
update dieir own data. 

For the user group 'Owners' the same pennission rigjits ai« specified as for flje 
'Customers'. Moreover, they are allowed to read all homes, to insert homes, to delete 

20 homes, and to update data concerning homes, but only fiv their own homes. The 

generic appUcation engine knows finm Ibe data model that there are relations fiom the 
data class 'Homes' to the data class 'Pecsons' (via the fields 'Agent* and 'Owner'). If 
the cunent user actuaUy is related to the current home, the geofsrio appl^ 
grants the user the additional peanissions. Furtheimorei on a field level it may be 

25 nidicatedwhi«ihfieldsmaynotbeupdated.OwnerearealsoaUowedtosdectrBntals. 
but again, only dieir own. 

For the user groiq) 'Agents' (he same pennissions are defined as for the user group 
•Owners'. Moreover, they are aUowed to add or delete objects in the data class 'Rentals', 
but only fi»r fiie homes of owners fliey rqjresent 

30 F<»tl» user group 'Mauiagei' it is indicated that they have all pemiissions for each 

data class, aUowing the 'manager' to select, read, insert, delete and iqxlate data in all 
data classes. 
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As a next step, triggers maybe entered, defined m the fonn of macio^s. This 
software q)pIication has two triggers: 

• Once a customer makes a reservation, an e-mail must be sent to the associated agent. 

• Once the agent confirms the reservation, an e-mail must be smt to the customer and 
5 (when desired) to the owner. 

Next, validation rules may be entered in ftie ^plication spedjScation, relating to 
constraiats for input data, e.g. check for double rental in a certain period. These 
validation rules may have the form of a flow chart in the computational specification, 
AftCT finishing the specification of data classes and fields, the gaieric plication 
10 engine is able to build a database 6 wfaidti suits the application specification just 
devebped 

As a final stq>, the default layout may be altered to a desired layout using the 
appearance specificafioa 9» 

Using this procedure, it is possible to have a woxkmg software applicatioa within 
1 5 a very limited amount of time. As soon as fields are specified, it is possible to test 
whether tfie software application suits the xequirements, by enterii^ the application 
specification in the generic plication eogine and review the runninig software 
^plication. New ideas or possibilities maybe directtytacluded in Hbe plication 
specification, tested and allowed or dismissed. 
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CLAIMS 

1. System for executing a sofiwaxe ^Ucation comprising 
a computer system cotmected to a plurality of ii^ut/ou^ut interfaces (1 1-14) and 
5 a database (6), 

the compute system being arranged for implementing a generic ^plication 
engine (5) and for receiving an application specification (1 0) as input for flic generic 
application oiginc (5), 

which generic ^plication eogine (5) is connected to the plurality of input/ou^ut 
10 intCTfaces and to die database (6), the generic plication engine (5) bdng arranged to 
use a set of functional components, such as database opa^tions, logical operations, 
presentation functions, user input/output interfaces, loggis^g and monitoring, to convert 
the application specification (10) into the sofhvaxe application, 
the application specification (10) comprising: 
15 a) a specification of a plurality of data classes, a data class being a desoiption of 

objects relevant within the software application, and the plurality of data classes 
forming a structure by means of relations; 

b) a specification of at least one user groiq) of the software a^lication, a user 

gxoup b^g defined as a group of users havhig ooinmon roles witii regard to ti^^ 
20 software application; and 

c) an assignment of peimissions to the at least one user gioup with respect to the 
plurality of data classes. 

2. System acoordiiig to claim 1, in i^ch a data class biecarv^ 
25 Wlicafion specification by ^pecil^ing an «teoded data class a^ 
more inherited ciiaracteristics of an associated super data class. 



30 



3. System accordizig to claim 1 or 2^ in which flie application specification (10) 
further comprises for each of the plurality of data classes a specification of a plurality 
of fields, each field representing an element for storing data values related to an obj ect 
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4. System according to claim 3, in vr^Gk a field lueraicby is defined in fb» 
q^Iicstion specification by ^ediying an extended field as oonqirising one or more 
inberited field cliaract«istics of an associated super field. 

5. System according to one of Ha claim 1 to 4, in which fixe application 
specification (10) fistfaer conqirises tax eadi of die plurality of data classes a 
specification of a plurality of cate^es, vAidi can be used to structure all data lelated 
toenotgect. 

6. System according to one of the claims 1 to 5, ia which the application 
specification (10) fiirther comprises a specification of a plurality of domains, a domain 
being a list of looki^) values that can be referenced to fi»m the specification of fidds. 

7. System according to one of the claims 1 to 6, in which the pemiissions are 
chosen from the group of: select permission; read peranssioo; update pemiission; insert 
permission; copy pomission; delete pennissioiL 

8. System according to one of the claims 1 through 7, in which the value of each 
permission is one of fiie group of: no; yes; foUow foreign oljeet; own; constrainL 

9. System according to one of the claims I tiuough 8, in which the application 
specification (10) comprises a computational specification (8) for describing finther 
con^nitational or logic fimctional parts of the st^tware application. 

1 0. System according to one of the elahns 1 tinougb 9, in which tiie appUcation 
specification (10) comprises an ^ipeanmce specification (?) for defining non-fimctiomd 
parts of the software explication, such as user i«^«rfacfl parts. 

1 1. System according to one of the claims 1 through 10, in which the application 
q)ecifioation (10) con^rises an XML file. 



12. System for building a software appKcation comprising an iirput/output device 
(22), memory means (2 1) and processing means (20) connected to the input/output 
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device and memoiy means, the iwocessdng means (20) being arranged for defining an 
plication $pecificadon (10), using the ii^t^ou^ut device (22), and to store die 
qjplication ^edficatlon (10) in fl»e memoiy means ^1), which ^plication 
^edfication can be input in a system for wcecuting a software q)pHcatioQ according to 
5 (me of the claims 1 dutiu^ ll. 

13. Mefiiod for executing a software application comprising 
inputting an plication specification (10) into a generic ^plication engine (5), 
which generic application engine (5) is connected to a plmality of iiqjut/output 
10 inteifeces and to a database (6), the generic application engine (5) being arranged to use 

a set of functional componraits, such as database operations, logical operations, 

presentation functions, user iziput/output interfeces, loggfaig and monitoring, to convert 

the ^plication specification (10) into the software application, 
the q>plication specification (10) comprising: 
15 a) a specification of a plurality of data classes, a data class being a dcsciij>tioh of 

objects relevant within the software application, and the plurality of data classes ' 

forming a structure by means of rdations; 

b) a q»eoification of at least one user group of the software plication, a user 
groiq) being defined as a gioi^ of users having common roles with regard to tibie 

20 software plication; and 

c) an assignment of permissions to the at least one user groi;?i with respect to flie 
plurality of data classes. 

14. Method according to claim 13, in which a data class hierarchy is defined in 
25 the appUcation specification by specifying an extended data class as comprising one or 
more inh^ted charactetistics of an associated super data class. 

15- Method according to claim 13 or 14. in which the application specification 
(10) fiiriher comprises for each of the plurality of data classes a specification of a 
30 plurality of fields, each field representing an element for storing data values related to 
an object 
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16. Method according to claim 15, in which a field hiesrarehy is defined in the 
application specification by sped^g an extended field as comprising one or more 
inherited characteristics of sn associated super field. 

17. Method accozding to one of the claims 13 through 16, in which the 
plication specification (10) fiirthar compiises for each of fte plurality of data classes 
a specification of aphaality of categories, which can be used to straoturc all data 
idated to an olqect, 

18. Method according to one of the claims 13 through 17, in which the 
appfication specification (10) fiirther conqmses a specification of a plurality of 
domains, a domain being a Ust of lookup vahies that can be referenced to fiom the 
specification of fields. 

19. Method according to one of the claims 13 through 18, in which the 
peraiisaions are chosen from the group of: select pemodssion; read pemussion: update 
penuission; insert permissior^ copy permissioi^ delete penniasion. 

20. Method according to one of the claims 13 throi^ 19. in which the values of 
eachpermissionisoneofthegtottpof. m; yes; Mow foreign olject; o^ra; constnunt 

21. Method according to one of the clahns 13 through 20. in which flie 
application specification (10) finttier comprises a computational specification (8) fi*r 
describing finther oompiitaiional or logic fimctional parts office soft^ appUcation. 

22. Method according to one of fiie claims 13 dnou^ 21, in which the 
application specification (1 0) fiufiier comprises an appeaxaoce q)ecifioation (9) for 
defining non-fimotional parts of the software appUcaiion. such as user inters parts. 

23. Method accordirig to one of the claims 13 through 22, in which the 
plication spedScation (10) is stored as an XML file. 



24. Method for buiWmg a software plication comprising 
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defining an q)plication specification (10) and stoziog tbe ipplicatioa s)}edfication 
(1 0), ix^ch applicaficm specificatian is azranged to be used in a metfiod for wecuting a 
software application accoiding to one of the claims 12 tbzou^ 23. 

5 25. Computer program product comprising computex readable code, which allows 

a computer when loaded with the computer readable code to inclement a generic 
^plication engine (S) as used in flie system according to one of the claims 1 to 11, or in 
the meOiod as used in the meOiod according to one of the claims 13 to 23. 

10 26. Computer program product comprising computer readable code, vMch allows 

a computer when loaded with the oon^uter readable code to define an application 
specification (10) which is.ad^ted to be entered in a generic application engine (5) 
running on the computer, the plication specification comprising: 

a) a specification of a plurality of data classes, a data class being a description of 
1 S objects relevant within the software application, and the plurality of data classes 

forming a structure by means of relations; 

b) a specification of ai least one user group of the software a|9plicati<m, a us^ 
grok^i being defined as a group of users having common roles wifii regard to the 
software application; and 

20 c) an asdgnmrat of p ennissions to the at least one user group with lesp eot to the 

plurality of data classes. 
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O computer system. To this end, the application specification (10) comprises a specification (7) of aplurality of data classes, a data class 
being a description of objects relevant within the software application, the plurality of data classes forming a structure by means of 
relations, a specification of at least one user group of the software application, a user group being defined as a group of users having 
^ conunon roles with regard to the software application, and an assignment of permissions to the at least one user group with respect 
to the plurality of data classes. 
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